1. Field of the Invention
The present invention generally relates to a dynamic e-business applications. More particularly, this invention relates to a method and apparatus of automatic method signature adaptation for dynamic Web service invocation.
2. Description of the Related Art
Dynamic e-business is the dynamic adaptation of e-business processes and associated systems to support changing business strategies and tactics. It enables enterprise software to be modeled to fit the required business processes, rather than the other way around. When companies in an industry use the same enterprise software and adapt their business processes to fit it, they inevitably conduct their business in the same way as their competitors. Flexibility in infrastructure design allows new processes to be tried and deployed to develop a competitive advantage by doing it differently than the competition. Dynamic e-business offers the same flexibility in business partner integration. Web services technologies enable dynamic e-business. The use of Web services as programmable objects with real-world actions is fundamental to dynamic e-business. By exposing business functions as Web services that can be accessible anywhere over the Internet, a company becomes integration-ready to jump on any emerging opportunity with a business partner, such as to merge business processes in a merger or acquisition.
Web service represents a revolution in e-business capabilities; it enables a dynamic e-business model, fosters collaboration with layered services, and opens the doors for new business opportunities. Web Service is defined by new technologies like Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), Web Service Inspection (WS-Inspection) Language (WSIL), and Universal Description, Discovery, and Integration (UDDI). These technologies include a model for exchanging XML information, a language for describing services, and a directory for finding new business partners, respectively. Together, they enable Web services, a powerful new paradigm for creating e-business applications by integrating reusable software modules supported on the Web.
SOAP defines a model for using simple request and response messages written in XML as the basic protocol for electronic communication. SOAP can be used with any transport protocol; HTTP is currently popular. SOAP messaging is often modeled as a platform-neutral remote procedure call (RPC) mechanism, but it can be used for the exchange of any kind of XML information. Creating clients to access the SOAP services published in UDDI, is a straightforward process if the developer knows the exact interface of a Web Service. Interacting with a “document-oriented” SOAP service requires the use of lower-level SOAP API calls. Envelope object containing header and body to be sent must first be created. Another widely used way is interacting with SOAP RPC service.
The steps for creating a client that interacts with SOAP RPC services are:
1. Obtain the interface description of the SOAP service and create a call object. This provides one with the signatures of the methods that one wishes to invoke. Also one can look at a WSDL for the services. The SOAP Call object is the main interface to the underlying SOAP RPC code.
2. Set the target URI and Set the method name that one wish to invoke in the call object and Pass in the URN that the service uses as its identifier in its deployment descriptor.
3. Create the necessary Parameter objects for the RPC call and set them in the Call object using setParams( ). Ensure one have the same number of parameters of the same types as required by the service.
4. Execute the Call object's invoke method, retrieve the Response object and then extract any result or returned parameters.
In the dynamic e-business area, it is very hard to match the input parameters and output result format in advance for the Web services Invoke in the e-business application. Customers, marketplaces, and search engines can find the company to do business. Upon finding a suitable service provider, the company binds to the provider to begin e-business transactions. To access a Web service, software only gets the WSDL description of interface information. WSDL can be provided to a potential user of a Web service for rapid integration by way of a Web link to the file, an e-mail attachment, or from the UDDI Registry directly. Any companies can publish their own Web Services to any categories in multiple UDDI registries. So the Web Services they published will have different service interfaces which contain different method signatures. The inventors refer to these Web Services as “heterogeneous Web Services.”
At the present time, even within a specific industry domain, there are no industrial standards, nor are there unified service definitions. Furthermore, neither the service definitions to be unified nor standardized are in the near foreseen future. Therefore, heterogeneous Web Services are going to be a fact of life for a while, which poses problems for dynamic e-business integration. This is because there is always a need for human intervention to read the WSDL for Web Services and then to correctly construct input parameters so that they match properly with the WSDL definitions. Such manual processes take time and cause errors.
The need for a manual process to construct and match input parameters for Web Services is a result of the limited information defined in current WSDL for Web Services interfaces, i.e. only the method name and type of parameters, which is too generic, as well as, limited to be adequate for a program to automatically invoke the target Web Service. The current WSDL does not describe semantic information as to how to construct each input parameter, i.e. what kind the parameter is representing. For example, a WSDL defines an input parameter to be a number (i.e. float type), which can be interpreted for anything. Is the number representing a measurement, e.g. kg, pound, foot, oz, or a temperature; or is it presenting the amount of money, which can be in US dollars or in UK pounds? Unless the desired semantic definitions are clearly specified, it would not be possible for programs to correctly construct the input parameters for automatic invocation. Similarly, problems exist for the need to adapt output results to the correct format and units. Hence, there is the need for the manual process in the conventional methods.